I think it would be good to add a more descriptive changelog. Can you add a line to describe what the purpose is, or how it should be used?

I don't believe this will work as intended, or at least not consistently.

If the instrumentation is imported before configuration is set, then these values will be None, and as a result will not exclude any paths nor hosts. This is uncommon for environment variables where things are set before the process starts, but if we start including ways to configure the Configuration object (e.g. set once), this will result in these global variables resolving before anyone can set the configuration.

Here's a short example:

from opentelemetry.ext.flask import FlaskInstrumentor # start of the file, so it loads, and sets the _excluded_hosts global
from opentelemetry import Configuration

Configuration().set(flask_excluded_path="/foo") # this will not honored, as the global was already set.

I think a safer approach would be lazy evaluation: have a getter than populates the value when it's called for the first time. Generally you can feel confident it won't be invoked until the first time it has to match the route, or after instrumentation.

I'm not sure I understand the use case. Configurations aren't able to be set, they are populated in the first instance that they are used by reading from the environment variables. If the instrumentation is imported, Configuration will just be set the moment that it is called.

Currently, there is no way to set Configuration pro grammatically, although we might allow this in the future (set it once, and then it becomes immutable). A lazy load getter seems to makes sense as well in this case. I believe we should have this in a separate PR, since that is more about changing the API of Configuration.

@ocelotl might have to weigh in, but I worry not doing this change now will result in a bug later on. I'll at least file an issue here.